문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 프로그래밍 언어 (문단 편집) === 정적 타입, 동적 타입 === * 정적 타입 언어 : 자료형(Type)이 고정돼 있는 언어. 간단히 얘기하자면 정수형으로 정의한 1은 계속 정수형 1로 남아있다. 이걸 실수형 1.0으로 바꾸려면 명시적인 형 변환(Type casting)을 해줘야 한다. 묵시적 형 변환이 이루어지는 경우도 있지만 제한적이다. [[C(프로그래밍 언어)|C]], [[C++]], [[Java]], [[C\#]] 등이 여기에 해당된다. * 동적 타입 언어 : 타입이 실행 시간에 결정되는 언어. 실행하기 전까지는 특정 식의 타입을 알 수 없다. 자료형이 그것을 처리할 함수(또는 메서드)에 따라 그때그때 바뀌는 언어. 예를 들어 정수형 1을 정의했어도 그걸 처리할 함수가 문자열을 받아들이게 설계돼있다면 자동으로 정수형 1을 문자 1로 바꿔준다. [[Python]], [[JavaScript]], [[Ruby]] 등이 여기에 해당된다. 동적 타입과 정적 타입의 차이는 타입이 컴파일 타임에 결정되느냐 실행시간에 결정되느냐 뿐이다. 파이썬도 개별 값들은 내부적으로 고정된 타입을 가지며 암시적으로 마구 변환되지 않는다. 다만 명시적인 조건 없이도 공통의 인터페이스를 구현하는 것들을 넣어주면 동작하게 되어 있다. 이런 개념은 "덕-타이핑"이라고 하고 동적 타입만의 특성은 아니며 정적 타입 언어에서도 구현이 가능하다. 단지 정적 타입 언어들이 추구하는 방향이 덕 타이핑과 맞지 않는 경우가 많기 때문에 잘 안쓸 뿐이다. 동적 타입 언어 중에서 자바스크립트는 암시적으로 자료형을 마구 변환해주지만 기능보다는 설계결함으로 간주된다. 정적 타입 언어 중에서는 C가 이런 무분별한 암시적 형변환으로 악명높다. 알아서 변환해준다는게 좋게들릴지 몰라도 막상 써보면 괴로워지는 경우가 더 많다. 정적 타입 언어가 별 거 아닌 것처럼 느껴질 수도 있지만 실은 프로그래머들을 짜증나게 하는 주범이 바로 형 변환(Type casting)이기 때문에 동적 타입 언어는 이런 점에서 매우 강점을 가진다. 특히 객체 지향 언어에서는 동적 타입 및 그것의 일반화버전이라 할 수 있는 덕 타이핑(Duck typing)이 프로그래머에게 수많은 혜택을 준다. 예를 들어 오리라는 타입과 닭이라는 타입이 있고 둘 다 날아오르는 기능이 있다면 정적 타입 언어에서는 상위 인터페이스를 추출하는 등의 부가 작업이 필요한데 덕 타이핑을 지원하는 언어에서는 그냥 넣어버리면 알아서 난다. 물론 단점도 있는데 고래 같이 못 나는 타입을 집어넣으면 실행시간 오류(런타임 에러)를 뱉어버린다는 것. 정적 타입 언어는 이런 문제가 없다...고 알려져 있지만 거짓말이고 정적 타입 언어도 닭은 닭인데 통닭 같이 못 나는 타입을 집어넣는 바람에(기술적으로는 해당 메서드가 구현이 안된 객체) 런타임 에러가 나올 수 있다. 그러나 이건 현실을 전부 고려하지 않은 반쪽짜리 시각이고, 요즘은 정적 타입 언어가 동적 타입 언어보다 훨씬 생산적이고 오류가 날 가능성을 줄여준다는 점이 정설로 굳어지고 있다. 당장 동적 타입 언어로 유명한 파이썬과 자바스크립트[* 정확히는 [[TypeScript]]로 개발하고 별도의 컴파일을 통해 JavaScript로 변환된 코드를 배포하게 되는 케이스. '''컴파일'''이라는 용어를 보면 알겠지만 위의 '해석 방식에 따른 분류' 문단을 모호하게 만드는 예시 중 하나다.]가 정적 타입으로 옮겨가려는 움직임을 보이는 것으로 알 수 있지 않을까? 위에 있는 예시는 거의 모두 현실과는 동떨어진 예제와 설명이다. 위에서 든 상위 인터페이스 추출이나 메서드 미구현 문제는 정적 타입의 문제가 아니라 객체지향의 문제로, 정적 타입과 하등 상관없고 오히려 동적 타입으로 객체지향 개발을 하려고 할 때 더 흔히 일어나는 문제들이다. 강하고 안전한 정적 타입 시스템을 지원하는 언어는 대부분의 일상적 프로그래밍 오류를 미연에 방지해준다. 가령 가장 기본적인 동작인 함수 호출의 사례만 봐도 이러한 측면을 쉽게 이해할 수 있다. 동적 타입 언어는 그 어떤 쓰레기 값을 인자로 사용해서 호출해도, 심지어 아예 인자의 갯수마저 틀려버려도 그 호출 코드를 런타임에 아무 의심없이 실행해버리고 예상치 못한 동작을 하며 디버깅에 애를 먹이기 일쑤다. 하지만 정적 타입 언어는 잘못된 호출을 하고 있다고 컴파일 시에 오류를 친절히 알려준다[* IDE를 사용한다면 굳이 컴파일까지 할 것도 없이 코딩 중 코드에 빨간줄까지 그어주며 설명해준다.]. 하스켈을 비롯한 강-정적타입 언어 사용자들이 "컴파일이 된다면 버그는 없다"고 하는 말이 빈 말이 아닌 것이다. 단순 사용 편의성 측면을 봐도, 최신 IDE 및 개발 도구들이 제공하는 코드 자동 완성이나 리팩토링, 정의 이동 등의 기능들은 컴파일 타임에 타입을 제대로 추론할 수 없으면 거의 동작하지 못한다. 똑같은 프로젝트[* 가령 JavaScript로 진행하는 프로젝트 vs. TypeScript로 진행하는 프로젝트. 전자의 경우는 값비싼 개발 도구를 사다 쓰는 거랑 [[날코딩|그냥 메모장으로 코딩]]하는 게 사실상 별 차이가 없을 지경으로 답이 없는 개발 환경이다. 물론 무료 개발 도구에서 제공하는 기능들도 TypeScript 쪽이 압도적으로 풍부하다. 이 문단에서도 언급했듯 JavaScript는 뭘 지원해줄래야 할 수가 없는 구조이기 때문.]를 진행해도 이런 고생산성 기능들을 제대로 활용하느냐 못하느냐에 따라 개발 기간이나 유지보수성이 천지 차이로 벌어진다. 참고로 하스켈([[Haskell]])은 정적 타입 언어다. 그런데도 하스켈 코드에는 형 변환 연산자가 없다. 이게 어찌된 일이냐 하면 하스켈 언어는 정적 타입 언어이지만 강력한 타입 추론 기능을 내장하고 있어 형변환을 언어 차원에서 자동으로 해 준다. 동적 타입 언어 역시 자동 형변환을 제공하는데 무슨 차이가 있냐면 그 형변환을 런타임에 하느냐 컴파일 타임에 하느냐의 차이다. 즉 버그가 발생하는 시점을 런타임(사용할 때)에서 컴파일 타임(만들 때)으로 끌어당긴다. 타입 추론 엔진은 딱히 하스켈 같은 선언형, 함수형 언어에만 도입할 수 있는 건 아니므로 신형 설계가 적용된 언어라면 명령형, 객체 지향 언어라도 타입 추론을 할 수 있다. 단지 정적 타입 언어로 유명한 C나 자바에 타입 추론 엔진이 없을 뿐이고, C#이나 [[Kotlin]][* 이쪽은 아에 자바처럼 [[JVM]]에서의 동작이 고려된 언어다. 프로그래밍 언어와 그 구현체는 별개로 구분되어야 한다는 전형적인 예시 중 하나라고 할 수 있다.] 등의 고생산성 정적 타입 언어들은 얼마든지 타입 추론을 지원하고 있다. 여기서 타입 추론은 묵시적 형 변환과 동의어가 아니다. 겉으로 보이는 건 묵시적 형 변환하고 똑같지만. 하스켈은 형 변환을 하는 게 아니라 형 변환도 타입 선언도 둘 다 필요 없도록 추론을 통해 한 번에 맞는 타입을 부여해준다. 이를 묵시적 형 변환처럼 쓰려고 하는 건 큰 착각인데, 같은 타입으로 볼 수 없는 두 위치에서 같은 변수를 사용하면 묵시적 형 변환이 되는 게 아니라 컴파일 오류를 내뱉는다. 하스켈이나 ML에 쓰인 타입 추론 엔진은 Hindley-Milner 시스템이라 불리는데, 명령형 언어 중에서는 [[Rust(프로그래밍 언어)|Rust]]가 이를 적용했었다(현재는 아님).저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기